home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / dcom / modems-part1 / 2544 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  11.2 KB
  1. Path: mips.pfalz.de!not-for-mail
  2. From: naddy@mips.pfalz.de (Christian Weisgerber)
  3. Newsgroups: comp.dcom.modems
  4. Subject: Re: USR - a PC modem company
  5. Date: 22 Jan 1996 15:54:14 +0100
  6. Message-ID: <4e08em$ida@mips.pfalz.de>
  7. References: <4d0urh$8rg@usenety1.news.prodigy.com> <DKzK41.E2@lazrus.cca.rockwell.com> <DL068x.IBy@freenet.carleton.ca> <4der33$e7e@usenety1.news.prodigy.com>
  8. NNTP-Posting-Host: mips.pfalz.de
  9.  
  10. davidsen@tmr.com (bill davidsen) writes:
  11.  
  12. > All I want is a way to do it myself, unless it's totally arcane it
  13. > would be a nice thing for someone to post to the net. Assuming that
  14. > USR has a protocol spec for this.
  15. > 
  16. > Want to send me a copy, USR?
  17.  
  18. Here's something I found in my mailbox one day. Translated from German
  19. by yours truly, original text available on request.
  20.  
  21. --------------->
  22.  
  23. Flash ROM Programming of the new USR Courier Modems
  24. ---------------------------------------------------
  25.  
  26. Note: Do not try anything described in this text without having a
  27.       working SDL.EXE at hand. Any error at an arbitrary stage can
  28.       result in erasure of the flash ROM.
  29.  
  30. Before you can feed new data to the flash ROM you will have to get
  31. in touch with your modem. For this purpose use the undocumented
  32. ^BE^GHmX^I^H command:
  33.  
  34. 1. Send the character sequence
  35.  
  36.         AT^BE^GHmX^I^H
  37.  
  38.    to the modem, where ^ marks a control character (so it is ten
  39.    characters altogether), *without* a terminating carriage
  40.    return. The modem acknowledges this with the character 3Fh,
  41.    E3h, or E4h. A look at the modem shows something happening: the
  42.    MR LED is off now. You have ten seconds to perform steps (2)
  43.    through (4). If nothing has happened by then the modem will
  44.    assume a timeout and return to normal operations.
  45.  
  46. 2. The echo-safe echo test.
  47.  
  48.    To ensure that no hacker is listening in and recording the
  49.    programming sequence, both computer and modem then change the
  50.    bitrate twice. First, switch to 19200bps and send a 'Q' to the
  51.    modem. Wait about 100ms, flush the input buffer, switch to
  52.    9600bps, and--ho!--the 'Q' sent at 19200bps will be returned at
  53.    9600bps.
  54.  
  55. 3. Immediately afterwards the original bit rate is restored. The
  56.    modem sends four additional bytes to the computer. Assuming a
  57.    Dual Standard V.34 Ready they are as follows:
  58.  
  59.       00h  Country code. SDL.EXE uses this to ensure that the bad
  60.            guys do not upload the American firmware to a PTT-
  61.            approved modem. 00h or E2h mean North America.
  62.            (Possibly only one of these means North America and the
  63.            other one "any country".)
  64.  
  65.       0Dh  Modem type. #13 is a Courier Dual Standard V.34 Ready.
  66.            The same firmware can also be loaded into modem types
  67.            2, 5, 9, or 12.
  68.  
  69.       00h  This must be zero. Conceivably, this is the version
  70.            number of the firmware programming scheme.
  71.  
  72.       00h  (Reserved; currently no meaning.)
  73.  
  74. 4. The next byte tells the modem how many 128k-banks of the flash
  75.    ROM to erase:
  76.  
  77.       00h  Nothing is erased at all. Can be used to abort the
  78.            operation in case a problem has occured.
  79.  
  80.       02h  The range C0000-FFFFF is erased (for transfer of old
  81.            pre-V.34 firmware or a new loader).
  82.  
  83.       04h  All of the ROM, 80000-FFFFF, is erased (for transfer of
  84.            V.34 firmware).
  85.  
  86.    Subsequently a 2-byte checksum is transmitted which will be
  87.    required for step (7) (see below). The algorithm to calculate
  88.    this checksum will be described below. The checksums for the
  89.    SDL releases available at the time of writing are:
  90.  
  91.      SDL 17.06.94 (firmware)    0Bh / 11h
  92.      SDL 17.08.94 (firmware)    FBh / E1h
  93.                   (loader)      49h / E8h
  94.  
  95.    If you have sent 00h to abort the operation a 2-byte dummy
  96.    checksum must still be appended.
  97.  
  98.    The modem acknowledges the erasure command with 15h.
  99.    (Details on the loader: see the section after the next one.)
  100.  
  101. 5. The modem now attemps to clear the specified ROM range and
  102.    returns the result of the operation:
  103.  
  104.       16h  =  erasure complete
  105.       1Bh  =  block erase error
  106.       1Dh  =  bad programming voltage
  107.  
  108. 6. After successful erasure the ROM can be reprogrammed. This is
  109.    accomplished by simply transmitting all of the new ROM image en
  110.    bloc to the modem, using XON/XOFF flow control.
  111.  
  112.    If the programming has been successful, the modem will return
  113.    14h. Otherwise it will produce one of the following error
  114.    codes:
  115.  
  116.       18h  =  bad line checksum
  117.       19h  =  bad CRC
  118.       1Ah  =  inter-gap timeout
  119.       1Ch  =  write error
  120.       1Dh  =  bad programming voltage
  121.  
  122.    The error codes can also occur anytime during the transfer. In
  123.    this case the programming must be aborted at once and must be
  124.    repeated completely.
  125.  
  126. 7. Finally the modem calculates a CRC over the data block and
  127.    acknowledges this with 14h in case of success or reports 19h,
  128.    respectively, if the checksum is incorrect. The calculation can
  129.    run for a maximum of 6 seconds.
  130.  
  131.  
  132.  
  133. Modem Firmware
  134. --------------
  135.  
  136. If you have been following this text closely, you certainly have
  137. been wondering how the modem recognizes the end of the firmware
  138. data. The solution is simple: apart from the actual firmware the
  139. image contains additional check and control data.
  140.  
  141. The transferred data consists entirely of small data blocks called
  142. "lines". Each line has a structure like this:
  143.  
  144.   Byte #        Content
  145.   ------------------------------------------------------
  146.   0             length of data field (n)
  147.   1 - 2         offset address of data block, MSB first
  148.   3             flag byte:  0 = normal data block
  149.                             1 = terminating data block
  150.                             2 = segment block
  151.                             3 = adress block
  152.   4 - n+3       data
  153.   n+4           checksum
  154.  
  155. The checksum is calculated by adding modulo 256 all bytes from 0
  156. up to and including n+3 and negating (one's complement) the
  157. result.
  158.  
  159. Segment blocks are always of size 2 and contain the segment
  160. address of the following data blocks, MSB first, in the data
  161. field. The first block is always a segment block. (If you do not
  162. know what segments and offsets are, you should familiarize
  163. yourself with the architecture of the 8086 CPU.) The modem saves
  164. the received "lines" at the given segment:offset address.
  165.  
  166. The terminating data block has always size 0.
  167.  
  168.  
  169.  
  170. Address Block and Loader Trick
  171. ------------------------------
  172.  
  173. Immediately before the terminating data block there is an address
  174. block of size 4, containing the segment:offset address (MSB first)
  175. at which the modem is to continue execution after the programming
  176. has succeeded. Normally, this starts power-on initialization code
  177. of the modem.
  178.  
  179. The new V.34-SDL uses this entry point to first transmit a new
  180. loader program (SDL message: "Transmitting loader..."). After the
  181. transfer, the address block of the loader program causes the newly
  182. transferred loader to be activated. It copies itself into the
  183. modem RAM, permitting the ROM to be erased completely and the
  184. transfer of the actual firmware.
  185.  
  186. Altogether, the V.34-SDL does the following:
  187. - start programming (steps 1-3)
  188. - erase ROM at C0000-FFFFF (steps 4-5)
  189. - transfer loader (about 6kB) (steps 6-7)
  190. - erase ROM at 80000-FFFFF (steps 4-5)
  191. - transfer firmware (about 312kB) (steps 6-7)
  192.  
  193.  
  194.  
  195. SDL.EXE
  196. -------
  197.  
  198. The download program features two undocumented parameters that
  199. might be useful for some applications:
  200.  
  201.      SDL /p     Skips the prompt and starts programming at once.
  202.  
  203.      SDL /u     Only seems to check the consistency of the
  204.                 firmware. /u allows for a couple of additional
  205.                 parameters. If you know your way around the
  206.                 Borland C runtime library, you are invited to find
  207.                 out their meanings...
  208.  
  209. The integrity of the firmware is checked by means of a 16-bit
  210. checksum every time SDL.EXE starts up. Thus direct patching of
  211. random ASCII data in SDL.EXE is not possible (ignoring the
  212. additional modem CRC).
  213.  
  214. Finding the firmware within SDL.EXE is rather simple. It always
  215. starts out with a segment block (02 00 00 02 ...) and ends with a
  216. terminating block (00 00 00 01 ff). In the V.34-SDL, the firmware
  217. is immediately followed by the loader which again starts with 02
  218. 00 00 02 ... and ends with 00 00 00 01 ff.
  219.  
  220. When extracting the firmware from SDL.EXE, attention must be payed
  221. to the fact that because of Intel linking technique the data is
  222. split into several segments of about 60000 bytes each, and that
  223. every segment is extended to a multiple of 16 bytes. These segment
  224. boundaries in the EXE file do NOT match boundaries between data
  225. blocks. The correct segment boundaries are only revealed by
  226. debugging since these segments do not have entries in the
  227. relocation table. There is a table of relative segment addresses
  228. followed by a table of segment lengths in the data segment.
  229.  
  230. The file addresses of the segments for the currently existing SDL
  231. releases are (no responsibility taken):
  232.  
  233.               | SDL 1994-06-17 | SDL 1994-08-17 | SDL 1994-08-25
  234.   Segment     |  Start  Length |  Start  Length |  Start  Length
  235.   ------------+----------------+----------------+----------------
  236.   Firmware #0 |  05410   ea2e  |  055b0   ea2e  |  055b0   ea2e
  237.   Firmware #1 |  13e40   ea65  |  13fe0   ea65  |  13fe0   ea65
  238.   Firmware #2 |  228b0   ea65  |  22a50   ea65  |  22a50   ea65
  239.   Firmware #3 |  31320   ea65  |  314c0   ea65  |  314c0   ea65
  240.   Firmware #4 |  3fd90   a7a6  |  3ff30   ea65  |  3ff30   ea65
  241.   Firmware #5 |                |  4e9a0   4e3c  |  4e9a0   531a
  242.   Loader      |                |  537e0   182b  |  53cc0   182b
  243.  
  244.  
  245.  
  246. Checksum
  247. --------
  248.  
  249. The 16-bit checksum used in steps (4) and (7) is not calculated
  250. from the transferred data but from all of the newly programmed
  251. memory including all unused bytes, which have the value FFh.
  252. Producing the checksum thus requires reconstructing the content of
  253. the modem ROM from the transferred data.
  254.  
  255. The algorithm depends on whether the whole ROM has been programmed
  256. or only the part starting at C0000. The calculation always works
  257. like this:
  258.  
  259.     - Initialize the checksum to FFFFh.
  260.     - Sequentially add all bytes of the range to be checked.
  261.  
  262. For the checksum from C0000 on the checked range is C0000 to
  263. F7FFFD, i.e. it is 37FFE bytes long. The calculation from 80000 on
  264. is done in two steps: First, the checksum for the range 80000-
  265. BFFFF is calculated and the result is stored at F7FFC (LSB first).
  266. The subsequent proceeding is analogous to that for a "short"
  267. checksum.
  268.  
  269. The following function is used for "adding" a single byte:
  270.  
  271.   int AddByte(int chksum, int b)
  272.   {
  273.     int  i;
  274.  
  275.     i  = (chksum ^ b);
  276.     b  = (i & 0xff)
  277.     i ^= (b << 4);
  278.     i  = (i >> 8) + ((i & 0xff) << 8);
  279.     i ^= (b << 3);
  280.     b  = (b & 0xf);
  281.     i ^= (b ^ (b << 7));
  282.  
  283.     return i;
  284.   }
  285.  
  286.  
  287.  
  288. Reading from Modem Memory
  289. -------------------------
  290.  
  291. For the purpose of porting SDL.EXE to a different platform, if
  292. there is already a reprogrammed modem at hand, the simplest way to
  293. find out the checksum is to read it directly from the modem
  294. memory. The command
  295.  
  296. AT G=ssss:oooo
  297.  
  298. displays a hexdump of the modem memory from address ssss:oooo on.
  299. The checksum is stored at F7FFE, i.e. for instance at F7FF:000E,
  300. LSB first.
  301.  
  302. <---------------
  303. -- 
  304. Christian 'naddy' Weisgerber                         naddy@mips.pfalz.de
  305.   See another pointless homepage at <URL:http://home.pages.de/~naddy/>.
  306.         -- currently reading: Timothy Zahn, Conqueror's Pride --
  307.